Stabilize SourceId hashes relative to the workspace
authorTyler Hall <tylerwhall@gmail.com>
Sun, 29 Jan 2017 22:55:44 +0000 (17:55 -0500)
committerTyler Hall <tyler.hall@lexmark.com>
Sun, 25 Jun 2017 21:45:37 +0000 (17:45 -0400)
commitdd02aa34eebe8203e6ebe19b5d9326f3b3ae5e8b
treecb03f75361f1567945667b21e4f79ff19e77b72d
parent58da6b05d47da76bd8309745ae1c271b948ae900
Stabilize SourceId hashes relative to the workspace

Currently a crate from a path source will have its metadata hash
incorporate its absolute path on the system where it is built. This
always impacts top-level crates, which means that compiling the same
source with the same dependencies and compiler version will generate
libraries with symbol names that vary depending on where the workspace
resides on the machine.

For paths inside the Cargo workspace, hash their SourceId relative to
the root of the workspace. Paths outside of a workspace are still hashed
as absolute.

This stability is important for reproducible builds as part of a larger
build system that employs caching of artifacts, such as OpenEmbedded.
OpenEmbedded tightly controls all inputs to a build and its caching
assumes that an equivalent artifact will always result from the same set
of inputs. The workspace path is not considered to be an influential
input, however.

For example, if Cargo is used to compile libstd shared objects which
downstream crates link to dynamically, it must be possible to rebuild
libstd given the same inputs and produce a library that is at least
link-compatible with the original. If the build system happens to cache
the downstream crates but needs to rebuild libstd and the user happens
to be building in a different workspace path, currently Cargo will
generate a library incompatible with the original and the downstream
executables will fail at runtime on the target.
src/cargo/core/package_id.rs
src/cargo/core/source.rs
src/cargo/ops/cargo_rustc/context.rs
src/cargo/ops/cargo_rustc/mod.rs